개요

쿠버네티스의 서비스에 대해 공부하다보면, 필시 kube-proxy에 대해서도 공부하게 된다.
그러면 또 공부하게 되는 게 프록시 모드고, 프록시 모드에는 iptables, nftables가 있다.
이런 게 있다는 것은 전부터 알고 있었지만, 이번 기회에 조금 더 자세하게 공부하고 싶어졌다.
iptables에 내용 정리는 조금 더 자세하게 해뒀다.

nftables

글들을 찾아봤는데, iptables 설정하는 것들 보면 진짜.. 개 귀찮고 복잡해보인다.
테이블도 무조건 딱 고정이라 설정할 때도 복잡한 게 이만저만이 아니고, 아까 위에서 봤던 arp라던가 하는 다른 테이블들에 대한 명령어가 따로 있는 것도 귀찮다.
이러한 문제를 타파하고자 나온 것이 바로 nftables로, 기존의 모든 table 머시기 툴들을 통합하고, 동시에 조금 더 효율적으로, 좋은 성능으로 규칙들을 세울 수 있게 만들어진 툴이다.
실제로 nftables를 사용할 때 동일한 기능을 하는 규칙들을 세웠을 때 성능이 좋다고 한다.

장점

• nftables uses a new syntax. The iptables command line tool uses a getopt_long()-based parser where keys are always preceded by double minus, eg. --key or one single minus, eg. -p tcp. In contrast, nftables uses a compact syntax inspired by tcpdump.

• Tables and chains are fully configurable. iptables has multiple pre-defined tables and base chains, all of which are registered even if you only need one of them. There have been reports of even unused base chains harming performance. With nftables there are no pre-defined tables or chains. Each table is explicitly defined, and contains only the objects (chains, sets, maps, flowtables and stateful objects) that you explicitly add to it. Now you register only the base chains that you need. You choose table and chain names and netfilter hook priorities that efficiently implement your specific packet processing pipeline.

• A single nftables rule can take multiple actions. Instead of the matches and single target action used in iptables, an nftables rule consists of zero or more expressions followed by one or more statements. Each expression tests whether a packet matches a specific payload field or packet/flow metadata. Multiple expressions are linearly evaluated from left to right: if the first expression matches, then the next expression is evaluated and so on. If we reach the final expression, then the packet matches all of the expressions in the rule, and the rule's statements are executed. Each statement takes an action, such as setting the netfilter mark, counting the packet, logging the packet, or rendering a verdict such as accepting or dropping the packet or jumping to another chain. As with expressions, multiple statements are linearly evaluated from left to right: a single rule can take multiple actions by using multiple statements. Do note that a verdict statement by its nature ends the rule.

• No built-in counter per chain and rule. In nftables counters are optional, you can enable them as needed.

• Better support for dynamic ruleset updates. In contrast to the monolithic blob used by iptables, nftables rulesets are represented internally in a linked list. Now adding or deleting a rule leaves the rest of the ruleset untouched, simplifying maintenance of internal state information.

• Simplified dual stack IPv4/IPv6 administration. The nftables inet family allows you to register base chains that see both IPv4 and IPv6 traffic. It is no longer necessary to rely on scripts to duplicate your ruleset.

• New generic set infrastructure. This infrastructure integrates tightly into the nftables core and allows advanced configurations such as maps, verdict maps and intervals to achieve performance-oriented packet classification. The most important thing is that you can use any supported selector to classify traffic.

• Support for concatenations. Since Linux kernel 4.1, you can concatenate several keys and combine them with maps and verdict maps. The idea is to build a tuple whose values are hashed to obtain the action to be performed nearly O(1).

• Support new protocols without a kernel upgrade. Kernel upgrades can be a time-consuming and daunting task, especially if you have to maintain more than a single firewall in your network. Distribution kernels usually lag the newest release. With the new nftables virtual machine approach, supporting a new protocol will often not require a new kernel, just a relatively simple nft userspace software update.

성능 비교

벤치마킹을 했을 때도 nftables가 훨씬 좋은 성능을 보여주는 것으로 보인다.^[1]

실습

엄청 자세하게 실습을 하지는 않으려고 한다.
이해하는 것을 주목적으로 잡았기도 했고, 나중에 내 클러스터를 업그레이드할 때 본격적으로 사용하면서 익히게 될 것 같다.

내 iptables를 확인해봤다.
이게 filter 테이블에 있는, 각 체인 별 규칙들이다.

이건 nat 테이블 쪽에 있는 체인들을 보는 건데, docker란 체인이 nat를 해주는 것을 확인할 수 있다.

이건 nftables의 설정 파일이다.
내가 설정한 게 없으니 당연히 아무것도 없다.

nftables 리스트를 확인해봤는데, 보니까 iptables-nft라는, iptables의 각종 것들을 nft로 변환해주는 툴로 리스트 업되는 것을 확인할 수 있었다.

조금 더 이쁘게 보기

iptables -L -n -v | awk '
{
    desc = $10
    for (i=11; i<=NF; i++) {
        desc = desc " " $i
    }
    printf "%-6s %-6s %-30s %-5s %-4s %-16s %-16s %-10s %-10s  %s\n", 
           $1, $2, $3, $4, $5, $6, $7, $8, $9,  desc
}'

들여쓰기 안 된 출력물을 보자니 화가 나서 조금 커스텀 했다.

대안

eBPF라는 것이 있다.
이것은 리눅스 커널 내부에 있는 훅을 통해, 사용자의 커스텀 코드를 커널 공간에서 실행하는 것이다.
다른 명령어들은 커널 공간에서 노출해주는 SCI(systen call interface)를 통해서만 각종 명령을 수행하기에, 이리저리 오가는 시간이 오래 걸린다.
그러나 eBPF는 커널 공간에서 원하는 기능이 수행되므로 수행 속도가 훨씬 빠르다는 장점이 있다.

사실 난 iptables가 전부 nftables로 교체될 것이라 생각했지만, 몇 가지 글들을 찾아보니 eBPF가 훨씬 나은 대안이라서 앞으로 이쪽이 대세가 될 것이라는 시각이 또 있다.^[2]
실제로 쿠버네티스 측에서도 Cilium이라는 eBPF기반 CNI가 거의 대세를 이루고 있는 실정이다.

https://www.kangtaeho.com/66
https://hayz.tistory.com/entry/번역-Iptables-및-Netfilter-구조에-대한-심층분석

관련 문서

참고